Easing the Transit ion to Software Mass Customization1

Although software mass customization offers the potential for order-of-magnitude improvements in software engineering performance, the up-front cost, level of effort, assumed risk, and latency required to make the transition to software mass customization are a prohibitive adoption barrier for many organizations that could otherwise benefit. BigLever Software has developed a software mass customization technology that lowers the adoption barrier, enabling software organizations to achieve the benefits of software mass customization with significantly less transition time and effort. This technology supports three different transition models for adopting software mass customization. 1 Software Mass Customization and its Benefits Software mass customization focuses on the means of efficiently producing and maintaining multiple similar software products, exploiting what they have in common and managing what varies among them. This is analogous to what is practiced in the automotive industry, where the focus is on creating a single production line, out of which many customized but similar variations of a car model are produced. The powerful, though subtle, essence of this description is the focus on a singular means of production rather than a focus on producing the many individual products. Once the means of mass customization is established, production of the individual products is more a matter of automated instantiation rather than manual creation. Real world success stories of software mass customization come from diverse areas such as mobile phones, e-commerce software, computer printers, diesel engines, telecom networks, enterprise software, cars, ships, and airplanes. Each of these examples relies on creating and maintaining a collection of similar software systems. By using software mass customization techniques to exploit what their software systems have in common and to effectively manage the variation, companies are reporting order of magnitude reductions in time-to-market, engineering overhead, error rates, and cost[1][2][3][4][5][6]. What is most interesting from these success stories, however, is that the tactical improvements in software engineering are large enough to have strategic impact on the 1.  Springer-Verlag business of a company. By bringing larger numbers of precisely customized products to market faster and with better quality than their competitors, companies have been able to assume market leadership. 2 Challenges of Software Mass Customization Many of the companies who have reported great success with software mass customization have also reported great challenges and costs in making the move to that model. Adoption times are often measured in terms of years and the costs in millions of dollars. Often, key architects and senior technical personnel must be taken off line for many months to prepare for the move to software mass customization. Often, organizational restructuring and process re-tooling are required. Although many organizations are now learning of the huge potential benefits of software mass customization, the associated costs, risks, and resources are a prohibitive adoption barrier for many. The tension between the potential benefits and imposing challenges of software mass customization is often manifest in the interactions between marketing and engineering groups in a company. Sales and marketing frequently encounter opportunities where customizations of their software products could result in additional revenue. From a business perspective, software mass customization represents a lucrative strategic model for dominating market share, expanding into new market segments, and closing complex deals with demanding customers. However, engineering must frequently resist customization requests because of the associated high level of effort, resources, costs, and risks. Why is software mass customization more difficult than simply (1) building a single software system, and then (2) building the collection of small variations? Why do we need a major shift to complex and heavyweight software engineering technologies, methods, processes, and techniques? The answer is that, over the past several decades, we have developed formal tools and techniques for building single software systems (item #1 above), but we have no formal tools or techniques in our arsenal for building and managing a collection of small variations for a software product line (item #2 above). To compensate for this void, software engineers historically have relied on informally contrived solutions such as configuration files, IFDEFs, assembly scripts, install scripts, parallel configuration management branches, and so forth. However, these informal solutions are not scalable; they are not manageable beyond a small number of product variations. Moreover they are code-level mechanisms that are ill-suited to express product-level constraints. More recently, research has focused on some of software engineering’s most powerful and complex solutions for managing product line variation, but these have the associated high adoption barrier. The current situation, then, can be summarized as follows. Software mass customization has the potential to bring order-of-magnitude improvements to an organization’s performance, but the practices up to this point combine a massive up-front investment at the highest organizational levels with unsatisfactory code-level mechanisms to actually manage the variabilities. The time is right for another approach. 3 Simplifying Software Mass Customization Using one of computer science’s most powerful principles, separation of concerns, BigLever Software has created BigLever Software GEARS, a software mass customization technology that enables organizations to quickly adopt a software mass customization business and engineering model[7][8][9][10]. GEARS works in conjunction with the existing tools and techniques, currently used for building single software systems, so that mass customization is a straightforward extension to single system engineering. The separation of concerns is applied so that the technology is independent of programming language, operating system, configuration management system, build system, and so forth. Furthermore, it does not depend on a particular domain modeling language, architecture language, or design language. By extending the existing single system technology set with a formal technology focused on software mass customization, software organizations can achieve the benefits of software mass customization with significantly less time and effort than has previously been required. Rather than timeframes of months and years, BigLever talks in terms of what can be accomplished the first day, week, or month. For example, a recent BigLever customer was able to convert their existing one-of-a-kind product into a GEARS production line with three custom product instances in less than one day. 3.1 BigLever Software GEARS BigLever Software GEARS provides the infrastructure and a development environment for creating a software mass customization production line. Revisiting the analogy to automotive mass customization, where a single production line is used to manufacture many customized variations of a car model, GEARS is analogous to the infrastructure and technology used to create the automotive production facility. That is, GEARS is used to create a single software production line, out of which many customized variations of a software system can be produced. Imagine, for example, that a company has already manually created three different variations of a software product for three different customers or different market segments. Because these product customizations were created under different deadlines, it was easiest to just create and maintain three independent copies of the system in parallel (for example, on different configuration management branches). However, the effort of parallel maintenance of these three system versions is taking its toll, and requirements for more customized variations are looming in the sales and marketing department. Using GEARS, these three system copies are consolidated into a single software mass customization production line. Software that is common among all three systems is factored out. For software that varies among the three, the GEARS infrastructure is used to encapsulate the differences at the point of variation in the source code, along with the logic descriptions for choosing among the differences at production time. With the software now structured into a single GEARS software production line, the three individual products can be assembled with the push of a button. The production line can be easily extended and maintained to accommodate new customized products, requirements, or defects. Note again that the focus shifts from developing and maintaining three separate products to developing and maintaining a single production line. 3.2 The Software Mass Customization Layer BigLever Software GEARS works at the granularity of files. By not intruding into files, GEARS remains neutral to programming language, compilers, operating system, editors, and so forth. GEARS works equally well with files that contain source code, documentation, test cases, requirements, and even binary multimedia files. Figure 1 illustrates where the GEARS software mass customization layer fits in, relative to conventional technology layers. At the bottom layer is the operating system’s file system. Configuration management extends that layer by providing management for file and system versions that vary over time. GEARS extends that layer by providing mass customization of system versions that vary at a fixed point in time. 3.3 GEARS Infrastructure, Development Environment, and Actuator GEARS comprises mass customization infrastructure, a mass customization development environment, and a mass customization actuator. The infrastructure structures software into a mass customization production line. The development environment has editors and browsers to view, create, modify, and maintain the production line. The actuator activates the production line to produce the individual software product instances. The software mass customization infrastructure of GEARS has three major components, feature declarations, product definitions, and automata. Feature declarations model the scope of variation in the production line. Product definitions model the product instances that can be created from the production line. Automata encapsulate source code variants that exist in the production line and the logic for selecting among the variants. The GEARS actuator is responsible for configuring a product instance from the source files, declarations, definitions, and automata in a production line. By actuating all automata in a production line, a complete product is configured. File System Configuration Management System BigLever GEARS Conventional software tools such as editors, build systems, defect trackers, compilers, debuggers, and test cases. Figure 1 The Software Mass Customization Layer of GEARS 4 Models for Adopting Software Mass Customization Organizations transitioning to software mass customization with BigLever Software GEARS can operate using one of three broad adoption models. We have termed these as proactive, reactive, and extractive. With the proactive approach, the organization analyzes, designs and implements a complete software mass customization production line to support the full scope of products needed on the foreseeable horizon. From the analysis and design, a complete set of common and varying source code, feature declarations, product definitions, and automata are implemented. This corresponds to the heavyweight adoption approach discussed earlier in Section 2, "Challenges of Software Mass Customization", while at the same time utilizing GEARS as the software mass customization infrastructure and development environment. With the reactive approach, the organization incrementally grows their software mass customization production line when the demand arises for new products or new requirements on existing products. The common and varying source code, along with the feature declarations, product definitions, and automata, are incrementally extended in reaction to new requirements. This incremental approach offers a quicker and less expensive transition into software mass customization. With the extractive approach, the organization capitalizes on existing custom software systems by extracting the common and varying source code into a single production line. Using the BigLever GEARS infrastructure, the feature declarations, product definitions, and automata are created as the commonality and variation is identified during the extraction. This high level of software reuse enables an organization to very quickly adopt software mass customization. Note that these approaches are not necessarily mutually exclusive. For example, a common approach is to bootstrap a software mass customization effort using the extractive approach and then move on to a reactive approach to incrementally evolve the production line over time. The following sections provide more detail on the extractive, reactive, and proactive approaches to software mass customization. 4.1 Extractive The extractive approach to software mass customization, illustrated in Figure 2, is appropriate when an existing collection of customized systems can be reused. It is most appropriate when the collection of systems has a significant amount of commonality and also consistent differences among them. It is not necessary to perform the extraction from all of the pre-existing systems at once. For example, a subset of the high-payoff systems might be extracted initially and then the remainder incrementally extracted as needed. The high level tasks for the extractive approach are as follows: 1. Identify commonality and variation in the existing systems 2. Factor into a single BigLever GEARS production line • create a single copy of the common software • create feature declarations that model the scope of variation among the existing systems • encapsulate variation points into automata • program the automata logic to map declaration parameter values to variant selections in the automata • create the product definitions for the desired product instances by selecting values for each of the feature definition parameters After the production line has been populated, product instances are created (with the push of a button) as needed via the actuator. Software mass customization now becomes the mode of operation as focus shifts to maintaining and enhancing the single production line. Figure 2 Extractive Model of Software Mass Cutomization Product 1 Product 2 Product 3